This invention generally relates to supporting business logic in computer applications. More specifically, the invention relates to methods and systems for managing and applying business rules for data used in computer applications.
Many applications include “business logic” as a part of the total function. This is in addition to application logic which is used to retrieve, present and store data; the “business logic” is usually in the form of extra constraints that are imposed on the data (beyond innate data integrity rules) to ensure that it is valid within that business application. The rules for the business logic are (at least from a programming point of view) more arbitrary than the core application logic. For example, a business rule might be that any new orders have to be at least 50 dollars in cost. This is in contrast to a base integrity rule that says that the order header must exist before the line items for that order can be added. Business logic also tends to change over time; frequently this is the major cause of updates to the application.
The traditional approach to this has been to write unique code to handle each business verification. Quite often, this code is intermingled with other code that is involved only with data presentation or storage. There are several problems associated to this approach:    1. It is difficult to find out just how a business rule has been implemented. The business logic may be totally mixed up with other processing so that it cannot be easily isolated and modified.    2. Since the business rules are coded in the same classes that are presenting the data, changing the rules means that many parts have to be changed. These changes may have unintended side effects because the business logic is not sufficiently isolated.    3. This limits the flexibility of the application and makes it hard to maintain.    4. Implementation of a business rule requires programming expertise. It cannot be done using visual programming techniques.    5. Changing a business rule requires changing the application code and reinstalling the application. This can be particularly annoying if the rules change frequently to adapt to changing business conditions.
If a rule is implemented in one place in the application, there is no way to verify that it will be invoked in all appropriate circumstances. Some parallel piece of application processing may also need the rule. If it is implemented twice to cover that situation, then there is no assurance that it will be found in both places when it needs to be modified.